iT邦幫忙

2026 iThome 鐵人賽

DAY 6
0
AI 自動化

從單一 Agent 到 Supervisor 架構:用 n8n 實作會自己分工的 Multi-Agent AI 部門系列 第 6 篇

Day 06|壓力測試:10 封刻意設計的信,單兵 Agent 其實比想像中強

  • 分享至 

  • xImage
  •  

這篇原本的暫定標題叫「單兵 Agent 的崩潰瞬間」。實際跑完之後,標題只好改掉,因為它沒有崩潰。

今天用 10 封刻意設計的信測試 Day 04 的單兵 Agent,每封跑 3 輪,看看它做對什麼、做錯什麼。

測試方式

10 封信各自針對一種常見的麻煩情境:沒給訂單編號、一封信問兩件事、同一位客人有兩筆訂單、FAQ 沒寫到的問題、客訴、施壓要折扣、轉寄一大串內容的信等等。

判準直接用 Day 04 那份 prompt 自己寫的規則,每封信只看三件事:資料有沒有講錯、客人問的事有沒有回答到、該標註 [需人工處理] 的有沒有標。

環境是 n8n 2.38.7 加上 gemma4:cloud,Temperature 0.2。每一輪都使用新的 thread_id,避免 Memory 讀到上一輪的回答(Day 05 提過我在這裡踩過雷)。

整體結果

結果 第 1 輪 第 2 輪 第 3 輪
符合規則 8 8 8
部分符合 2 2 2
違反規則 0 0 0

三輪的判定完全一致。在 Temperature 0.2 之下它非常穩定,下面觀察到的現象都不是偶發。

但是「符合規則」跟「沒有問題」是兩回事,細節才是這篇的重點。

逐封來看

T01 標準查單

「你好,我的訂單 A10293 想問一下什麼時候會到?謝謝」

它呼叫 get_order 查單,出貨日、物流商、單號、預計到貨日都正確。唯一的瑕疵是開頭寫了「王先生您好」,資料只有姓名,性別是它自己判斷的。

T02 沒給訂單編號

「請問我上禮拜買的東西什麼時候會到?」

沒有呼叫工具,也沒有自己編一個訂單編號,而是請客人提供編號,完全照 prompt 規則走。

T03 一封信問兩件事

「想問 A10294 出貨了嗎?另外淺焙的豆子可以做冰滴嗎?」

兩件事都有回答:A10294 備貨中,淺焙適合冰滴。但回信裡多了一句「我們會盡快為您安排出貨」,這是一個資料沒有提供依據的承諾。

T04 同一位客人有兩筆訂單

「我的訂單到了嗎?」寄件人是王小明,他有 A10293 已出貨、A10296 待付款兩筆。

三輪都只能請客人提供訂單編號。原因很單純,它唯一的工具只能用訂單編號查,沒辦法用 email 找出這位客人名下有哪些訂單。

這樣處理不會出錯,客人只是要多寫一封信。但它不會跟你說「我少了一個用 email 查的工具」,只會默默換個方式應付過去。

T05 FAQ 沒寫到的問題

「想問下單的時候可以指定星期六上午送嗎?我平日不在家。」

三輪都回答「無法指定到貨時間,建議收到物流通知後,再跟快遞人員協調」。

這個答案跟好豆選物的正式政策一模一樣。問題是,Day 04 prompt 裡那 7 條 FAQ 根本沒有寫到指定配送時段。它是依照一般電商的慣例推測出來,剛好猜對。

這封信是我這次最在意的一封。假如公司政策剛好跟常見做法不同,它一樣會很篤定地給出常見做法,而且從回信上完全看不出它是查到的還是猜的。

T06 客訴

「第三次了!!包裝又是破的,豆子撒了一半在箱子裡。我要求全額退款,不然我會去消保會申訴。訂單 A10295。」

三輪都正確標註了 [需人工處理]。

T07 客訴加上查單

「這已經是第二次延遲了,你們的服務真的很爛。A10304 現在到底在哪?」

三輪都有標註 [需人工處理],第 1 輪還順便查了單、附上物流單號。

T08 施壓要折扣

「我在你們家買了快兩年了,這次想買磨豆機,有沒有折扣?沒有的話我就去別家買了。」

它沒有給出任何折扣碼,照規則 7 請客人看官網公告。

不過依好豆選物的規定,議價類的信應該交給人處理,只是 prompt 裡沒寫這條,它自然不會這樣做。

T09 已開封的咖啡豆想退貨

「A10298 的耶加雪菲喝起來太酸了不喜歡,已經開封了,可以退嗎?」

政策回答正確,已開封的咖啡豆不接受退貨。但它寫了「這部分請您見諒」,跟 prompt 明確禁止的「敬請見諒」幾乎一樣。

T10 轉寄的出貨通知

這封信只有一句「東西咧???」,底下是轉寄的出貨通知,還夾著秋季新豆的行銷區塊、公司地址和取消訂閱連結。

第 1 輪它從轉寄內容中找出了 A10300,也查到正確的物流資訊。可是三輪都在開頭加了 [需人工處理]。客人只是急著問包裹,不算客訴,這樣會讓一封 AI 可以自己回的信,平白佔掉客服人員的時間。

整理一下

編號 測試重點 結果 觀察到的問題
T01 標準查單 符合 從姓名推測性別
T02 沒給編號 符合 無
T03 一信兩問 符合 沒有依據的承諾
T04 兩筆訂單 部分符合 工具不足,只能反問
T05 FAQ 沒寫 符合 答案正確但沒有出處
T06 客訴 符合 無
T07 客訴加查單 符合 無
T08 要折扣 符合 prompt 沒寫轉人工就不會轉
T09 已開封退貨 符合 接近禁用詞
T10 轉寄雜訊信 部分符合 不必要的轉人工

成本方面,不需要查單的信只呼叫模型 1 次,prompt 約 850 tokens;需要查單的信呼叫 2 次,合計約 2,000 tokens。延遲大多在 1 到 3 秒之間。這組數字會是之後比較的基準。

我從這 10 封信得到的結論

gemma4:cloud 搭配一份寫得還算清楚的 prompt,已經能處理大部分常見情境。如果只看分數,很難說服人一定要拆成多個 Agent。

但這 10 封信也暴露了幾種靠改 prompt 很難根治的問題。T05 答對了,卻沒辦法分辨它是查到的還是猜到的;T04 缺工具,它不會主動說;T08 規則沒寫到,它就照常回信;性別稱謂、接近禁用詞的句子,prompt 寫了還是會冒出來。

不過 10 封信的樣本實在太少。明天把同一個 Agent 丟進完整的 50 封評估信,看這些問題在更多情境下會變成什麼樣子,再決定要怎麼拆。

小結

單兵 Agent 在 10 封壓力測試信上三輪都是 8 封符合、2 封部分符合,而且結果穩定。比起分數,讓我更在意「答案正確但沒有出處」這種情況,還有工具缺口、規則漏洞都不會被主動回報。


上一篇
Day 05|給 Agent 記憶:Simple Memory 的 Session ID 該怎麼設
下一篇
Day 07|為什麼要拆:50 封評估信裡那些「看起來很正常」的回信
系列文
從單一 Agent 到 Supervisor 架構:用 n8n 實作會自己分工的 Multi-Agent AI 部門 共 17 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言